Monad + Linq

[kfa...@thuban.org]

Has anybody tried this yet? I suppose it'd take some work internally
to be able to create the expression trees automatically out of script
blocks, but I think it'd work fairly well. Both are basically pipeline
architectures:

DataContext(conn).GetTable("Customers").Where({$_.City="London"}).OrderBy({$_.LastName})

[Jeffrey Snover]

Monad will look to support LINQ in V2. We are really excited about LINQ.
It is taking Monad's take on traditional Shell concepts (pipelining and
fuzzy typing) and making them available to Systems Programming languages.
You'll see more and more of this happening as the intent is to take some of
Monad's classes and migrate them to the BCL (Base Command Library). From
the very beginning we designed Monad with the idea that there should be an
easy glide path from Monad to C#. We think we do a pretty good job of that
today because our syntax is largely aligned with C#'s and the using Monad
teaches you the .NET objects - the classes, the methods, and properties.
(Some of the Monad devs are actually prototyping portions of Monad in Monad
before writting them in C#) The big hitch as been that the native way to
think about things in Monad is a pipeline and no such concept existed for
C#. Well now it does so the transition from Monad to C# will be even
easier.

The future just keeps getting better all around!
--
Jeffrey Snover [MSFT]
Windows Command Shell Architect
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

<kfa...@thuban.org> wrote in message
news:1127171854....@g47g2000cwa.googlegroups.com...

[Jouko Kynsijärvi]

Jeffrey Snover wrote:
> Monad will look to support LINQ in V2.

So this could mean that AD/SQL/WinFS/etc providers/cmdlets could actually
convert "where-object { $_ }" syntax into an expression tree and then to a
LDAP/SQL query filter that is processed on the server? If yes, then this is
exactly what is was looking for! (see bug 342484741)

> The future just keeps getting better all around!

Definitely!

[Jeffrey Snover]

> So this could mean that AD/SQL/WinFS/etc providers/cmdlets could actually
> convert "where-object { $_ }" syntax into an expression tree and then to a
> LDAP/SQL query filter that is processed on the server?

Yes.
AND it would also deal with things like |SORT |GROUP |etc
BUT the backend (SQL vs XML vs whatever) will determine what expressions
are supported
Right now, you can put any code you want into the WHERE clause but
SQL will not
support everything so you'd be limited to what SQL can express.
Actually, you should
be able to use any expression but it will only be "accelerated" if
you use the SQL
subset (which is really quite expressive).

--
Jeffrey Snover [MSFT]
Windows Command Shell Architect
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Jouko Kynsijärvi" <jouko.ky...@nospam.nospam> wrote in message
news:O60aRGev...@tk2msftngp13.phx.gbl...

[kfa...@thuban.org]

Actually, I've suggested, and I think it was already suggested
internally, that you could serialize an expression tree and ship it to
Yukon. Yukon, as a CLR hoster, could deserialize the tree and execute
it local to the data itself. This would effectively be a remoted
sproc, and would avoid any limitations inherent in SQL syntax. Of
course, this would be the determination of the data context object or
some such provider.

Pushing pipelining into the BCL? That could make me a very happy man.
I imagine it'd fit right in with WWF.